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40 FIELD OF THE INVENTION 

The field of the invention relates to converting a non-object oriented computer 
language to an object-oriented computer language more particularly, the invention relates 
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to converting a non-object oriented computer language to an object-oriented computer 
language while maintaining existing code structure and data structures. 
BACKGROUND 

Computer languages have evolved over time as computer systems have become 
5 more complex and as instruction execution speed has increased. Society is becoming 
more dependent on computer systems and advance computer-programming languages. 
However, before the last decade, most computer programs were written in non-object 
oriented languages. The non-object oriented computer languages implemented simple 

CI logic statements which allowed the following: basic data input and output operations, 

ul 

?^ 10 implementation of subroutines which could be called and returned from, and the focus of 

-j\ 

ui 

the programmer to be placed on the procedures of the language or the program. Within 

t " 

. rt 

III the last several years however, a paradigm shift has occurred toward programming in an 
CI object-oriented language. In an object-oriented language, the progranmier focuses on the 
data in the program and the methods that manipulate that data rather than focusing on the 
^ 15 procedures of the language. Object-oriented languages are usually easier to understand. 
Examples of object-oriented language include C-h+ and Java. 

In an object-oriented system, you solve your problem in terms of objects which 
occur in the context of the problem and objects are almost everything in common object- 
oriented systems. Objects allow you to define entities relevant to your particular program 
20 rather than strictly expressing your solution to a problem essentially in terms of 
characters and numbers as is required by non-object oriented language. 

A class is a term used to describe a specification for a collection of objects with 
common properties. A class is also a collection of data and methods that operate on that 
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data. The data and methods describe the behavior and state of an object. Classes are 
hierarchical, that is subclasses inherit behavior from the classes above it. A class 
describes the requirements for a collection of objects and may be thought of as a template 
which defines what makes up the particular object. A class definition of an object lists all 
5 the parameters that the programmer needs to define the object of that particular class. 
Instance variables or attributes of a class are commonly used to define these parameters. 
Objects can include the methods that operate on it as well as the data that defines the 
object. This allows for ease in programming. Typically, object-oriented programs take 
longer to design than non-object oriented programs, as care must be taken to design the 

10 classes that will be necessary for your program, however, object-oriented programs are 
also much easier to maintain and expand. 

However, many businesses have spent considerable time, effort and money in 
developing computer programs to control all aspects of their organizations. Many of 
these programs were developed using standard programming techniques that were 

15 available prior to the development of object-oriented design. As such, businesses must 
consider the time necessary and the cost associated with modifying or replacing existing 
programs with easier to maintain object-oriented programs. Therefore, any advancement 
in the ability to convert a non-object oriented language program to an object-oriented 
language program would be advantageous. 

20 SUMMARY OF THE INVENTION 

Object Oriented ADN and a method for converting a non-object oriented 
language to an object oriented language is shown. First, an existing object oriented 
language must be selected. An object oriented language is selected to provide for ease of 
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translation with regard to syntax and grammar. Second, the non-object oriented language 
is selected. This is the language the programmer desires to be converted to an object 
oriented language. The requirements for the new object oriented language are then 
defined. The requirements can be expressed in a document including a set of 
5 enhancements to be made to the existing language. Next, the specific syntax and 
grammar are selected. The object oriented extensions are then developed. The object 
oriented extensions allow for the existing language and data structure to be developed 
coextensive in the object oriented environment. Programs written in the existing 
Q language are still executable in the new object oriented language. Finally, the new object 

^'i 10 oriented language is prepared based upon the criteria outlined previously. 

HI 

^; The Object Oriented ADN including an application logic function, data types and 

■j\ 

^1 scopes, a class for message instancing, client workload models, server process 

rt infrastructure, database models, operating system models, statistics capability, utility 

Ci classes, and garbage collection. 

m 

□ 15 

BRIEF DESCRIPTION OF THE DRAWINGS 

A better understanding of the present invention can be obtained when the 
following detailed description of one exemplary embodiment is considered in conjunction 
with the following drawings, in which; 
20 FIGURES lA-lB are flow diagrams of the conversion to object oriented 

environments process; 

FIGURE 2 is an exemplary embodiment of the existing ADN language code; and 
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FIGURE 3 is an exemplary embodiment of the new object oriented ADN 
language code. 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 
5 In the description which follows, like parts are marked throughout the 

specification and drawings with the same reference numerals, respectively. The drawing 
figures are not necessarily drawn to scale and certain figures may be shown in 
exaggerated or generalized form in the interest of clarity and conciseness. 
Q FIGURES lA-lB illustrate a method of converting a non-object oriented 

SI 10 computer environment to a new object-oriented computer environment. The process 
y| begins with Start 100 on Figure lA. Next, in Step 102, the existing object-oriented 
J- computer environment must be identified. An existing object-oriented computer 
environment would include commercially available object-oriented languages such as 
r| Java, which is provided by Sun Microsystems Inc. Typical benefits of a commercially 

i 

O 15 available object-oriented computer language include improved application extendibility, 
maintainability, data hiding and encapsulation which makes code reuse easier, and the 
ability to allow the user additional power and flexibility to implement complex 
applications. Further, if Java is selected, the automatic garbage collection feature and 
associated object reference counting design is particularly useful in certain languages, 
20 especially simulation language. Java's syntax is also based on C++ language syntax. 
Java's selection may also be appropriate if the legacy language is also based on C or C++ 
language syntax. Next, in Step 104, the non-object oriented computer environment is 
identified. The non-object oriented computer environment includes languages which 
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implement structure other than the object-oriented methodology and are desired to be 
converted to an object oriented system. Thus, older existing languages which pre-date 
the use of object-oriented analysis and design are potential candidates for this conversion. 
In one embodiment, the Application Definition Notation (ADN) language would fall in 
5 this category as ADN is a special purpose programming language for scripting the 
behaviors of clients and servers and is not written in an object oriented form. ADN was 
especially designed for use with a simulation tool and includes the features to handle 
concurrency, message passing, simulation time management, and simulated resource 
usage. The ADN features include C-like assignment in control flow statements, variables 

10 having different scopes and lifetimes, concurrent programming using threads and 
processes, simulation control and resource usage statements, input/output statements and 
a wide variety of built in functions. Next the requirements for the new object-oriented 
computer environment must be defined in Step 106. A requirements document can be 
produced from a set of enhancement requests and an understanding of the non-object 

15 oriented computer environment. Further, basic requirements such as reusability would 
factor in the determination of defining the requirements. The requirements document can 
be used to identify any future functionality or improved functionality of the non-object 
oriented computer environment. Also, the requirements document can identify 
functionality present in the non-object oriented computer environment which will be 

20 advanced through the modification or conversion to the object-oriented computer 
environment. Next in Step 108, compatible granmiar and syntax is selected. The 
grammar and syntax of the new object-oriented computer environment must be 
compatible with the non-object oriented computer environment. The compatibility is 
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necessary as the non-object oriented computer environment language is to be extended to 
provide the new object-oriented capabilities. The beginning of the selection of the 
grammar and syntax occurs in Step 102 during the identification of an existing object- 
oriented computer environment. The existing object-oriented computer environment 
5 should be selected so that a standard object-oriented language specification is available 
and can be used as a reference document. Within this reference document, the use of the 
semantics of the reference language can be used as a guide to ensure that the functionality 
is implemented as part of the object-oriented conversion. Further, when the syntax or 
rl grammar is not exact, then the non-object oriented computer environment syntax should 
^"-■1 10 be followed as closely as possible to minimize the effort in determining the new object- 



oriented capabilities. Any language key words not present in both the existing object- 
oriented computer environment and the non-object oriented computer environment 
should be reserved for use in subsequent implementation. Next, the object-oriented 
extensions are developed in Step 110. The object-oriented extension design should 



C'l 15 satisfy several goals. First, the object oriented computer environment should not burden 
the legacy system user in cases where the new OO functionality is not used. The 
interface to the new OO features should appear natural and easy to learn for the legacy 
system user. Second, the object oriented features of the new object oriented computer 
environment should be able to access the non-object oriented computer environment 
20 information so that existing applications can take full advantage of the new object 
oriented functionality. The non-object oriented computer environment application 
integrity should be preserved through the internal creation and management of key 
structures including structures as processes, threads and/or messages. 



Ill 



HI 
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In one embodiment, to preserve the integrity of the legacy system while giving the 
user more control, an object implementation was designed to include a header structure 
and a data structure. The object header structure was defined for use by all objects in the 
design. The mapping of all user-defined information is made to secondary structure. The 
5 object header points to either a user defined structure or a. non-object oriented computer 
environment data structure. By this approach, the non-object oriented computer 
environment information can be accessed in the same way as other object-oriented 
information. Second the object reference type was added to the semantics of the non- 
p| object oriented computer environment generic variable so that it was able to access any 
%| 10 type of information in the new object-oriented computer environment. Next in Step 112 
fl on Figure IB, the general purpose utihty classes were developed. No general purpose 
Jf'^ Utility classes existed in the non-object oriented computer environment. Therefore, to 
i| drive the full functionality of object-oriented operations, the general purpose utility 
Q classes must be added. Next in Step 1 14 the new object-oriented computer environment 
Cn5 is prepared. In preparing the new object-oriented computer environment, the 
requirements defined, the grammar and syntax selected, and object-oriented extensions 
must be considered to implement and develop the new object-oriented computer 
environment to accomplish the goals of completeness and ease of use. These steps of 
preparing the new object-oriented computer environment and in particular, the actual 
20 code generation, is not listed herein for brevity as various methods are available for code 
generation once the requirement specifications, grammar and syntax selected, and object- 
oriented extensions are developed. Any of various common code generation techniques 
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are usable and their use does not detract from the spirit of the invention. The method 
ends in Step 116. 

Referring now to Figures 2 and 3, examples of the ADN code and object-oriented 
ADN code are shown respectively. Figure 2 includes a portion of the ADN code which 
5 was prepared prior to the conversion to the object-oriented ADN. The file shown is the 
system.ADN. Figure 3 shows the object-oriented ADN code for the system.ADN after 
conversion to the object-oriented ADN. Through the method described previously, the 
ADN code was transformed to object-oriented ADN. The object-oriented ADN however, 
'll still possesses many of the same parameters and data structures contained in the original 

"==5 

[|i 10 ADN. For example, on page 2 of Figures 2 and 3, the variable constants INITIALIZES vc 

; • 3 

\^ 202 and 302 are set to zero in both figures. However, on page-7 of Figure 3, the object- 

S 

oriented functionality and syntax can be seen when the classes are address through the 
J^f use "PUBLIC" statements 304. Further, on page-7, the class and instance variables are 
declared 306. However, as can be seen on page-9 of Figure 3 and page-8 of Figure 2, the 

: r? 
LI 

1^15 ADN program language which was used in the pre-object-oriented and 204, is present in 
the object-oriented and 308. Therefore, implementing the method describe herein, the 
functionality and data accessibility was imported from the non-object-oriented language 
to an object-oriented language. 

The controlling code for the object oriented ADN, which was prepared according 
20 the to method described previously, is attached hereto as Attachment A. The object- 
oriented ADN is a programming language for simulating the behavior of computer 
systems. The object-oriented ADN now supports multiple object-oriented features 
including classes, inheritance, constructors, method overloading, packages, interfaces and 
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abstract classes. The class describes a collection of data objects (i.e. constant, variables 
and arrays) and methods (i.e. behaviors, functions and constructors) that may use data 
objects. The definitions may include constants, variables, arrays, behaviors, functions 
and constructors. If the declaration of an object is preceded by the keyword "public", 
5 then the object is visible outside the class. Otherwise the object is only visible within the 
class. The class is nothing but a template. Defining a class allocates no storage to the 
data objects in the class. It is the instances of the class that allocate storage and 
manipulate the data. 

A constructor is a special function within a class that is evoked automatically 
10 when a class is instantiated. The name of the constructor must be the same as the name 
of the class. The body of the constructor must execute in zero simulation time. 
Simulation time is calculated, not recorded as actual time. Simulation time is the amount 
of time necessary to accomplish a task if the task was being done in an actual computer 
system. As the software is simulating the computer system, the software can execute 
15 tasks with zero simulation time, thus that time is not included in the time analysis of the 
computer system. Simulation time is important because performance statistics are 
calculated from the simulation times at which events occur. Simulation time is 
maintained in a double precision floating point variable that measures the number in 
seconds from when the simulation begin. 
20 A behavior is a collection of ADN code that is invoked as a procedure. Its body 

may take simulation time to execute. It can take parameters as inputs and can return 
multiple values as outputs. A variable is declared by specifying its type, its name, and an 
optional initial value. A constant is a variable or array whose value cannot change during 
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execution. A constant is created by preceding the declaration of a variable or array with 
the keyword "final". 

A class is instantiated using the new operator. Instantiating a class creates a new 
instance of the class by allocating the needed storage, invokes a constructor for the class 
with the provided parameter values and returns a reference or pointer to newly created 
instance. 

Within a class there may exist multiple functions or multiple behaviors having the 
same name, as long as each function or behavior has different number of parameters. 
This is called "Method Overloading". When an overloaded function or behavior is 
invoked, the version having the same number of parameters as values being passed is 
invoked. Method Overloading allows implementing several variations on a method and 
can be used in place of a single method having a variable number of parameters. 

A package is a collection of constants, variables, arrays, behaviors, functions, 
classes and interfaces. A package is used to group related objects, making some of the 
objects visible outside of the package and hiding others within the package. A package is 
not instantiated. The objects in a package are referenced using their simple names. If the 
declaration of an object in a package is preceded by the word "public", then that object is 
visible outside the package. Otherwise, the object is visible only within the package. If 
the same name appears in multiple package directives, all the objects are considered to be 
a part of the same package. This allows a package to be defined in a non-contiguous 
pieces spanning several files. 
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Several key ADN features in existence before the object-oriented extension were 
enhanced during the conversion, adding significant value to the objected-oriented ADN. 
The features are as follows: 

Application Logic. Originally, ADN application logic was exclusively 
5 implemented in ADN global behaviors that resemble conventional programming 
subroutines. Simple logic statements were provided for conditional testing, looping, and 
data input and output operations. Performance statements were provided to account for 
hardware resource usage. Simulated send and receive statements were provided for inter- 
process communication. A set of built-in utility functions rounds were available to 
10 behaviors. 

After Object Oriented ADN, application logic could also be defined in class 
behaviors providing logic encapsulation, a key feature in Object Oriented ADN 
reusability. In addition, the user-defined Object Oriented ADN function was introduced 
in both global and class-contexts. The Object Oriented ADN function is limited to zero 

15 simulated time logic that can be invoked within the context of an expression evaluation. 
The class-context function is equivalent to the traditional Object Oriented method. The 
class constructor, a special function, was added for the initialization of a newly 
instantiated object. This can be seen through a comparison of the application logic 206 of 
the pre-Object Oriented ADN shown in FIGURE 2 with the application logic 310 of the 

20 Object Oriented ADN shown in FIGURE 3. 

Data Types. Before Object Oriented ADN, data consisted of type-less constants, 
variables, and arrays that took on the type of the data currently being held. Valid data 
types were Integer, Real, String, and Undefined. To conserve memory, 1, 2, 4, 8, and 16 
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bit array elements were also available. Associative arrays provided a means of storing a 

data values with a string value as a subscript. 

After Object Oriented ADN, the former type-less variables are given the type 

designation of Generic. The object reference is added to the generic type. In addition, 

5 strongly typed variables of Integer, Real, String, and class-type are added to provide the 

same data type capability available in traditional Object Oriented languages such as Java. 

Examples can be seen in the adn.y file attached as the computer program listing appendix 

submitted on compact disk and include the following: 

rl array _initjlist: expr 
SlO f$$-^l;} 
S j I array _init_list \ ' expr 

m {$$^$1^1;} 
^ I array Jnitjht \ ' 

^, { $$ = $1; I 

;!15 ; 

111 

n 



datajelementjype: GENERIC 

{$$ = (Inst *)GENERIC; } 
I VARIABLE 

1 20 {$$ = (Inst *)GENERIC; } 

) I CONST 

{ 

modif\= FINAL_mo; 
$$ = (Inst *)CONST; 

25 ; 

I STROP 

{$$ = (Inst *)STROP; } 
\REALOP 

{$$ = (Inst *)REALOP; } 
30 I INTOP 

{$$ = (Inst *)INTOP; } 

I TYPE 

{$$ = (Inst*)$l; } 
I STRING 
35 f 

$$ = (Inst *)$!; data_elementjoken = STRING; 

} 

I ASSOCIATIVE 
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/ $$ = (Inst *)ASSOCIATIVE; } 
I DATUM 

I $$ = (Inst *)DATUM; } 
I INTOP ICONST BIT 
( 

if( strcmp($2,"16")==0)f 

$$ = (Inst *)INTEGER16; 

} 

else if( strcmp($2. "8") ==0)f 
$$ = (Inst *)INTEGER8; 

} 

else if( strcmp($2, "4") ==0){ 
$$ = (Inst *)INTEGER4; 

} 

else if( strcmp($2, "2") ==0)f 
$$ = (Inst *)imEGER2; 

} 

else if( strcmp($2, "1 ") == 0 ) { 
$$ = (Inst *)INTEGER1; 

} 

else { 

yyerror( "Invalid Integer modifier"); 

} 

} 

data_element_type2: /* null */ 

{$$ = (Inst *)GENERIC: J 
I GENERIC 

f$$ = (Inst *)GENERIC: J 
I STROP 

{ $$ = (Inst *)STROP; } 
I REALOP 

{$$ = (Inst *)REALOP; } 
I INTOP 

{$$ = (Inst *)INTOP; } 

I TYPE 

{$$ = (Inst *)$!;} 
I STRING 

{$$ = (Inst *)$!; data_element_token = STRING; J 
I ASSOCIATIVE 

{$$ = (Inst *)ASSOCIATIVE; } 
\ INTOP ICONST BIT 
{ 

if( strcmp($2, "16") == 0 ) { 

$$ = (Inst *)INTEGER16; 

I 
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else if( strcmp($2, "8") == 0 ) f 
$$ = (Inst *)INTEGER8; 

} 

else if( strcmp($2, "4") == 0 ) ( 
$$ = (Inst *)INTEGER4; 

I 

else if( strcmp($2, "2") ==0){ 
$$ = (Inst *)INTEGER2; 

I 

else if( strcmp($2, "1 ") == 0 ) { 
$$ = (Inst *)INTEGER1; 

I 

else { 

yyerroti" Invalid Integer modifier"); 

} 

} 



Data Scope. Before Object Oriented ADN, the available data scopes consisted of 
model global including behavior names, simulated file, table and index names. In 
addition there were process local, thread local, and behavior local data scopes. 

After Object Oriented ADN, the data scopes were expanded to include package 
scope 312, class scope 314, and object instance scope 316. These added data scopes 
provide the data hiding and logic encapsulation necessary in the creation of reusable 
model components. 

Process and Thread Instances. Before Object Oriented ADN, process and thread 
structure instances were created and managed by internal logic. Selected state data was 
accessible through a set of built-in functions. 

After Object Oriented ADN, classes were defined for processes and threads. 
Examples can be seen in the Utilities.adn file attached as the computer program listing 
appendix submitted on compact disk and include the following, noting that the 
constructors are native and private: 
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//- 

// *** process and thread support *** 
//- 

5 //must match front end oft_Process structure definition in Software JJtil 

//allows any defined fields to be accessed by ADN 

public final class ses_Thread { 

10 private integer reserved; 

private Integer object _ptr; // ptr to associated tjObject 

private ses_SharedMessageQueue 
fSharedMessageQueue; 

private native constructor sesJThreadi ); // used internally 



15 

\ 

J 



} 

public final class sesJProcess { 



\ 20 private integer object _ptr; // ptr to associated tjObject 

private sesJThread fMainThread; 
private ses fSharedMessageQueue fSharedMessageQueue; 
native private constructor ses_Process(); // used internally 



p25 ; 

1=^ Message Instances. Before Object Oriented ADN, message structure instances 



111 were created and managed by internal logic. Selected state data was accessible through a 
set of built-in functions. 

After Object Oriented ADN, a class was defined for the message. Through this 
30 class, message fields may be accessed by the ADN user. The server classes use this class 
to handle the routing of service requests to the corresponding service behavior. Instances 
of the message class are accessible in the operating system logic where message activity 
is intercepted. Examples can be seen in the Utilities.adn file attached as the computer 
program listing appendix submitted on compact disk and include the following, noting 
35 that the constructors are native and private: 
//• 
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// *** message support *** 
/A 

//must match tJMsg structure definition in Software JUtilMessage.sim 

5 

public final Class ses_Message ( 

private native constructor ses_Message(msg_ptr) Retums(msg_ref); 

10 public native static function associatedMsg(msgjptr) Retums(msgjref); 

public native function sendToHardware(target_id,Kbytes) RetumsQ; 

private Integer object _ptr; // ptr to associated tjObject 
private Integer statStack; // tJStatStack * 
15 private Real send jtime; 

private Real receive Jime; 
private Real reply Jime; 



I public Real message Jbytes; 

111 20 public Datum dataf ]; //struct Datum * also int ndata 

t s ii 

private Integer nextMsg; // t_Msg * 

public Integer sending j>roc_sn; 
25 public Integer receiving_proc_sn; 

r| private Integer client _proc_sn; 

n| private Integer timeout _proc_sn; // <0 means stale 

30 public Integer msg^rotocol; //protocol 

private Integer iDbTransaction; // associated transaction of sending 

proc 

private Integer msgjype; // t_MsgType type; 
35 private Integer I bit forward; 

private Integer 1 bit svcState; 
private Integer 1 bit local; 
private Integer I bit xfrDb; 
private Integer 2 bit passCount; 



40 



Client Workload. Before Object Oriented ADN, the logic for a client workload 
was generated as an ADN behavior executing under a special user process. Client 
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workloads initiated the execution of behavior logic on a computer. Workloads could 
include human factor think time or could be expressed in terms of inter-arrival time. 

After Object Oriented ADN, the default functionality remains unchanged. By 
adding state data and additional logic, a user can define significantly more complex 
workload models. For example, the public factory behavior 318 of FIGURE 3 is shown. 
A client workload object can be created in a similar manner. 

Server Process. Before Object Oriented ADN, server processes were specified 
through a graphical user interface (GUI) which in turn generated ADN behaviors 
according to internally defined patterns and user supplied information. Services are 
specified by ADN behaviors supplied by the modeler. 

After Object Oriented ADN, server process infrastructure was designed and 
implemented as ADN classes. The new server infrastructure can be seen in server.adn 
attached as the computer program listing appendix submitted on compact disk 

Database Server. Before Object Oriented ADN, a built-in Oracle model provided 
the only significant database modeling capability. This feature allowed for the definition 
of cache size, block size, and individual named tables and indexes sizes. The semantics 
for a database transaction were supported in terms of starting and committing a 
transaction and collecting response statistics per transaction type. A transaction could be 
defined in the logic of a behavior to use select, insert, update, and delete operations on 
table rows. Operations such as update could optionally simulate row level locking. 
Distributed, central, and parallel Oracle model functions were supported. 
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After Object Oriented ADN, users can create models that involve significant data 
modeling. An example of the database server modeling capability can be seen in 
dbms.adn attached as the computer program listing appendix submitted on compact disk. 

Operating System. Before Object Oriented ADN, a default parameterizeable 
5 operating system model was supplied with the product. A user could create a modified 
operating system model although there was a substantial risk that the integrity of the 
model infrastructure would be compromised. 

After Object Oriented ADN, the operating system model logic was encapsulated 
in an operating system class. With this new design, a user can safely extend the operating 
10 system without disturbing the original logic. Examples include the base operating system 
functionality 320 of FIGURE 3 and a user defined operating system extension shown in 
user^extensions.adn attached as the computer program listing appendix submitted on 
compact disk. 



15 able to control which statistics would be collected and reported. 

After Object Oriented ADN, a user definable statistics capability was 
implemented as a set of Object Oriented ADN classes. A user defined query of built-in 
statistics during simulation was also added. Examples can be seen in the Utilities.adn file 
attached as the computer program listing appendix submitted on compact disk and 

20 include the following: 

public class ses_Statistic { 



Statistics. Before Object Oriented ADN, all statistics were built-in. The user was 



25 



// constants 

static final integer discrete = 0; 

static final integer continuous = 1; 

static final integer delta — 0; 
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# • 

static final integer absolute = 1; 

//state fields (must match tJStatistic in ADNparser.Statistic 
private integer /Handle; 
5 private integer JT ype; 

private string fl^ame; 

private integer fl^percentiles; //for liveDistribution 

//interface to Workbench statistic accessor methods 
10 // - 

public native function count( ) retums(number_samples); 

public native function deviationQ retums( deviation); 

public native function durationQ retums( duration); 
15 public native function maximum() retums(maximum_value); 

public native function minimum() retums(minimum_value); 
III public native function mean() retums(mean_value); 

'4l public native function name() retums(name_string); 

[^l public native function reporting( state) retums(); 

f I 20 public native function sample( value) retums( ); 

J^f public native function sampleAbsolute( value) retums( ); 

public native function type( ) retums( type_string); 
pi public native function value() retums(last_sample); 

public native function variance( ) retums( variance); 

h 25 

Uh private native Function defineDiscrete(prefix) retumsQ; 

CI private native Function defineContinuous(prefix) retumsQ; 

nl private native Function registerQueryStatistic() retumsQ; 

CI public native Function isActiveO retumsQ; 

h 30 

public native function registerService(serviceRefserviceName) retumsQ; 

// constructors 
// 

35 

//used by sesJStatisticsManagerxreateQueryStatistic 
//note: locateStatistic sets statType and statHandle 

public Constructor ses_Statistic( aName ) f 
40 fName = aName; 

fT ype = 2; // query stat type 
this. registerQueryStatistic( ); 

I 

public Constructor ses_Statistic( aName, aIntervalWidth ) { 
45 fName = aName; 

fType = discrete; 
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public function createlntervalStatistic( aName, aIntervalWidth ) [ 
ses_Statistic tIntervalStat; 

generic tStatMgr = ses^gStatMgr; // overcome lookahead problem 
tIntervalStat = new ses_Statistic( uName, aIntervalWidth ); 
thisMdd_interval( "^UDD%d^" + aName, aIntervalWidth, tIntervalStat ); 
tStatMgr,fDiscreteStatisticGroupAnsertStatistic( tIntervalStat ); 
retum( tIntervalStat ); 



Utility Classes. Before Object Oriented ADN, there were no general-purpose 
utility classes. 

After Object Oriented ADN, several utility classes were added, including the 
following: a list class for handling lists of objects; a list iterator class for accessing 
individual objects in a list; a semaphore class for use in controlling access to data; and 
logic that can only be processed by one thread at a time. Examples can be seen in the 
Utilities.adn file attached as the computer program Usting appendix submitted on 
compact disk. 



//used by ses_StatisticsManagerxreateDiscreteStatistic and 
// ses_StatisticsManager. createContinuousStatistic 



public Constructor ses_Statistic( aUxxPrefix, aName, aType ) f 
/Name = aName; 
JType = aType; 
switch ( fType ) f 




I 
I 
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Garbage Collection. Before Object Oriented ADN, memory management of all 
dynamically created structures such as processes, threads, and messages were built-into 
the modeling system. 

After Object Oriented ADN, memory management of the objects can be explicitly 
instantiated by a user. A system of object reference counts and automatic garbage 
collection were implemented based on the Java language semantics. The following 
functions were included and can be seen in ADNparser30.sim attached as the computer 
program listing appendix submitted on compact disk: init_gc_proc, incr_ref„count, 
decr_ref_count, and object_destroy. 

Many of the advancements of the Object Oriented ADN are disclosed herein, 
however, the Object Oriented ADN code is attached as the computer program listing 
appendix submitted on compact disk, which is hereby incorporated by reference. 

The foregoing disclosure and description of the invention are illustrative and 
explanatory thereof and various changes to the size, shape, materials, components, and 
order may be made without departing from the spirit of the invention. 
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